The present invention relates generally to financial transactions, particularly to customers requesting credit transactions with merchants, and more particularly to financial transactions conducted with a financial institution portable payment device issued by a financial institution, such as a credit card that, that may be used both in a retail transaction and in a transit fare transaction.
Portable payment devices can take many forms and are used in a great variety of financial transactions. The portable payment devices can comprise, for example, smart cards, payment tokens, credit cards, debit cards, stored value cards, contactless cards, cellular telephones, Personal Digital Assistant (PDA) devices, key fobs, or smart cards. The financial transactions can involve, for example, retail purchases, transit fares, access to venues, etc. In all such transactions, the portable payment device users (consumers) are concerned with convenience and the merchants with whom they deal are concerned with ease of transacting with their customer-consumers.
Typically, financial institution portable payment devices issued by a financial institution (FIPPD) are used in an on-line fashion (e.g., a point of service that is connected to a payment processing system during a transaction). The information from the FIPPD may be transmitted on-line to an issuer during a retail payment transaction for purposes of authorizing the use of the FIPPD for that transaction. The issuer may review parameters of the transaction such as transaction amount, credit history, card authenticity, and other factors when determining whether or not to authorize or decline the transaction.
Some merchant transactions are so unconventional that on-line FIPPD authentication and verification schemes cannot be accommodated. For example, the ability to go on-line in a transit environment such as a subway or bus system, or a venue access environment such as a stadium or concert hall, may be problematic because of the lack of real time communication and lack of network systems for such environments. This is due in part to the need in such environments to process a transaction within about 300 ms, a transit system industry standard, and thereby allow 30 to 45 patrons per minute access into a facility of the transit system such as a subway or a bus. Moreover, a bus on an over-the-road bus route may not have wireless or other communication systems to allow any real-time dialogue with any other systems outside of the bus, such as for online fare assessment or online admission ticket/voucher/card authorization. As such, the transit fare payment and collection process cannot be performed effectively using a conventional on-line authentication and approval process. This absence of network connectivity in a transit environment presents a difficulty whenever effective fraud prevention requires an on-line authentication of the consumer's means of access, such as an admission ticket, voucher, or access card, in order to determine whether the consumer is entitled to access and has sufficient funds to cover the cost of the desired transaction (fare for riding on the transit system).
Further, conventional on-line modes of payment are challenged when the value of a transaction is not known during the time of rendering of a good or service. In a transit environment, a fare calculation may depend upon the actual travel distance, direction of travel, station entry and exit locations, mode of travel (subway, bus, water taxi), consumer category (student, senior), and/or times of use (peak, off-peak). Such parameters can be unknown prior to rendering the service.
Moreover, the fees levied in conventional on-line modes of payment make their application into the transit environment impractical. Such fees may be fixed fees, such as ten cents ($0.10 US) per transaction, or variable fees such as five percent (5%) of the transaction value. These fees are levied at each node in the authorization, settlement, and clearance phases of the collection process, namely by the acquirer, the payment processor, and the issuer who may each levy fees at various phases. Typically, transit transactions have nominal transaction values (e.g.; a typical transit fare is about two dollars ($2.00 US) thereby making the overall levied fee, relative to the transaction value, substantial. Supporting the application of these payment fees to each of thousands of fare transactions processed everyday may become too costly and burdensome for the transit system.
Traditionally, transit fare calculation and collection have occurred in a closed system involving an off-line scheme. In a closed system, the transit company may issue its own transit portable payment device, such as a read/write smart card, wherein the transit portable payment device carries the necessary credentials and data to allow completion of a transaction at the fare device itself (turnstile, farebox, or other Point of Service). In this case, there is no additional processing required at the time of the transaction outside of the interaction between the card and the fare device. Rather, the card is authenticated and read by the fare device, logic is performed by the fare device to apply transit system fare policy, and the card is updated (rewritten) to finalize the transaction details including a deduction of any stored value for the cost of fare. The fare device may additionally query a hot list, negative list, or black list utilizing the card number and/or other card-specific data which, if not on these lists, the transaction will be completed and the cardholder will be allowed access into a facility of the transit system such as a subway terminal or bus passenger compartment.
The closed transit system, however, has its drawbacks. In a closed transit system, the transit portable payment device and transit readers at each station or route must be able to perform fare computations based on data stored and retrieved from a rider's access card, and subsequent card terminals/readers must be able to access data written to the rider's access card at previous stations. This requirement places a significant processing burden on the transit system terminals and/or fare processing systems and increases the cost of implementing the infrastructure for such systems. As fare rates and other relevant information generally change over time, this also increases the demands placed upon such systems for maintenance of accuracy.
Moreover, one transit portable payment device may not be compatible with all of the fare devices within a rider's travel plan. This can become a significant problem if a consumer wishes to utilize more than one transit system during a day's commute, such as by using multiple transit agencies or venues within a single geographical area that provide ridership both in and among different jurisdictions, cities or locations.
The present transit environment presents several challenges, including:                A common necessity that there can be only one transit portable payment device for each transit agency or group of cooperating agencies that cannot be used for other such agencies or groups;        The desire to accommodate transit system user's transaction speed expectations while minimizing risk to the transit agency for collecting payment for services rendered; and        The limitation that most financial institution portable payment devices are ‘read-only’ and do not have read/write capabilities at the Point of Service, with the consequence that such devices will not store the rider's transit chronology data—thus making the rider's fare calculations somewhat difficult with such devices.        
In addition to the transit system rider's desire for a fast transaction speed when accessing a transit system facility, there are security and other risks associated with the use of a FIPPD that is designed for on-line authorization when it is otherwise used in an off-line transaction. These risks include, but are not limited to:                Authentication: the lack of card/terminal authentication creates a high potential for fraud through counterfeiting techniques;        Fraud: transit transactions cannot be authorized on-line in real time as designed. With such off-line transactions, a negative list (i.e., a list of rejected cards based on the unique card number) stored at each transit fare device is the primary mechanism to deter fraud. This is sub-optimal since the negative list would presumably grow unbounded as more FIPPD are issued;        Fare Cost Calculation: where the cost of a transit transaction is dependent upon the immediate rider history for the card (entry/exit/length of travel, transfers, etc.), the rider's transit fare cannot be calculated at each gate or farebox because the rider's immediate history of travel cannot be stored, written or resident on the FIPPD due to the requirements of the issuing financial institution;        Data Security/Storage: protection of cardholder data in a transit fare system may prove difficult. Tracking data in the form of a primary account number (PAN) for a FIPPD would require the transit system to collect and store this data securely, which is not something transit fare systems commonly do presently. If implemented, this requirement presents added cost and security concerns to both the transit system and its riders; and        Certification: arranging for an issuer of the FIPPD (e.g., the banking organization) to approve of a particular card reader mechanism in a transit environment may prove difficult. Currently, FIPPD readers must be approved by financial payment organizations. This is not something transit system providers are required to do at present, and if implemented, adds additional costs including that of administrative overhead.        
What is needed in the art is the payment and collection of transactions utilizing a FIDDP device within the above environments, including access fares to transit systems and venues, that overcome the challenges and disadvantages of the prior art.